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(54) Electronic billing with updateable electronic bill summary 



(57) An electronic bill payment network includes a 
plurality of user network stations associated with differ- 
ent users, a plurality of biller network stations associ- 
ated with different billers, and a central network station. 
A first user station operates, in real time, to transmit 
information relevant to an amount of an available bill 
and an instruction to pay the available bill. A first biller 
station operates, in real time, to receive the transmitted 

40 
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information and to compute the amount of the available 
bill based upon the received information. The central 
network station operates to receive the computed 
amount of the available bill and the transmitted pay 
instruction, and to direct payment of the computed 
amount of the available bill based upon the transmitted 
instruction to pay that bill. 
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Description 

RELATED APPLICATIONS 

[0001] This application is a continuation-in-part of s 
pending Application Serial No. 09/017,169, entitled 
"Distributed Data Accessing Technique", filed February 
2, 1998. 

FIELD OF THE INVENTION 10 

[0002] The present invention relates to electronic 
bill presentment and more particularly to electronic bill- 
ing with updateable electronic bill summary present- 
ment. 15 

BACKGROUND OF THE INVENTION 

[0003] There are two prevalent models for elec- 
tronic bill presentment that are currently used in indus- 20 
try. The first is an aggregation model 1 0, which is shown 
in Figure 1. In its simplest form, the aggregation model 
1 0 includes a customer 1 2, an aggregator 1 4, and a plu- 
rality of billers 1 6. The customer 1 2 can be, for example, 
an individual person, a family, or a business. The aggre- 25 
gator 14 can be a financial institution (Fl) such as, for 
example, a bank. Alternatively, the aggregator 14 can 
be a separate entity which acts of behalf of a sponsor 
18, which can also be an Fl such as a bank. Each biller 
16 can be of any billing institution type such as, for 30 
example, a local telephone company, a local electric 
company, a retail outlet, or a national long distance tele- 
phone company. 

[0004] Each biller 16 provides customer- related 
invoice data to the aggregator 14. The aggregator 14 35 
serves as an intermediary between each biller 1 6 and 
the customer 12 by providing bill presentment directly to 
the customer 12, potentially on behalf of the sponsor 18. 
[0005] There are two variants of the aggregation 
model 1 0 resulting from the ownership, or "branding": of 40 
the presentation experience and the communication 
channel between the aggregator 14 and the customer 
12. In one variant, the aggregator 14 may offer aggrega- 
tor-branding, thus totally owning both the presentation 
experience and the communication channel between 45 
the aggregator 1 4 and the customer 1 2. In the other var- 
iant, the aggregator 14 may offer sponsor-branding, 
thus staying "behind the scenes" in terms of the presen- 
tation experience and supporting the communication 
channel between the aggregator 14 and the customer so 
12 on behalf of the sponsor 18. 
[0006] The second prevalent model for electronic 
bill presentment is a biller direct model 20, which is 
shown in Figure 2. In its simplest form, the biller direct 
model 20 includes a customer 12 and at least one biller 55 
16. In the biller direct model 20, each biller 16 retains 
the customer-related invoice data and the full relation- 
ship with the customer 12 (i.e., the presentation experi- 



2 

ence and the communication channel). The customer 
1 2 may have software for providing a capability similar 
to Web browser bookmarking so as to allow easy navi- 
gation between billers, and thus some level of virtual 
aggregation. However, there is no actual aggregation 
such as with the aggregator 14 of the aggregation 
model 1 0 described above. 

[0007] The above-described models present a 
dichotomy between a sponsor-centric view and a biller- 
centric view of bill presentment. That is, the aggregation 
model 10 allows the aggregator 14 and/or the sponsor 
1 8 to use customer-related invoice data, bill present- 
ment, and the communication channel between the 
aggregator 14 and the customer 12 for cross-selling or 
other peripheral services. The biller direct model 20, on 
the other hand, insures that control of customer-related 
invoice data, bill presentment, and the communication 
channel between the biller 16 and the customer 12 
remains with the biller 16. 

[0008] Also, neither of the above-described models 
adopts a truly customer-centric view. That is, neither of 
the above-described models allow a customer 12 to 
interact directly with individual billers 16 while retaining 
the benefits of interacting with a single aggregator 14 
such as, for example, the ability to retain a single 
authentication and log-in procedure and a common bill 
presentation framework. Further, neither of the above- 
described models allow a customer 1 2 to retain the ben- 
efits of interacting with a single aggregator 14 while 
allowing the aggregator 1 4, billers 1 6, and sponsor 1 8 to 
retain certain preferences such as, for example, the 
ability to retain control of customer- related data and a 
communication channel with each customer 12. 
Accordingly, it would be desirable to provide a more flex- 
ible data accessing technique. 

OBJECTS OF THE INVENTION 

[0009] One object otthe present invention is to pro- 
vide a distributed data accessing technique that allows 
a customer to interact directly with individual billers 
while retaining the benefits of interacting with a single 
aggregator. 

[0010] Another object of the present invention is to 
provide a distributed data accessing technique that 
allows a customer to retain the benefits of interacting 
with a single aggregator while allowing the aggregator, 
billers, and sponsor to retain control of customer-related 
data and a communication channel with each customer. 
[0011] Another object of the present invention is to 
provide a real time distributed data accessing technique 
that ensures payments of the correct bill amount. 
[0012] The above-stated objects, as well as other 
objects, features, and advantages, of the present inven- 
tion will become readily apparent from the following 
detailed description which is to be read in conjunction 
with the appended drawings. 
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SUMMARY OF THE INVENTION 

[0013] In accordance with the invention, an elec- 
tronic bill payment network includes a plurality of biller 
network stations each associated with a different biller, 5 
a plurality of user network stations each associated with 
a different user, and a central network station. Real time 
network communications is used to transfer information 
between the applicable user network station, applicable 
biller network station and the central network station. As 10 
used herein, the phase "real time" is defined to mean 
during a single on-line session involving a user seeking 
to view and, if desired, pay a bill. 
[0014] More particularly, a first user network sta- 
tion, associated with a first of the users, is operable, in 15 
real time, to transmit information relevant to an amount 
of an available bill. The transmitted information could, 
for example, be a gas or electric meter reading, of the 
amount of product ordered or used etc., which is 
required to determine, e.g. compute, the amount of the 20 
bill. Alternatively, the relevant information could be indic- 
ative of a disputed portion of a previously computed bill 
amount. In the latter case, the amount which will be 
determined could, for example, reflect a requested 
adjustment to the previously computed bill amount. 25 
[001 5] A first biller network station, associated with 
a first of the billers, is operable, in real time, to receive 
the transmitted information and to determine the 
amount of the available bill based upon the received 
information. As discussed above, this may be either a 30 
first determination of the bill amount or a determination 
of an adjusted bill amount. 

[0016] The central network station is operable, 
again in real time, to receive the determined amount of 
the available bill. The central station is also operable to 35 
receive a pay instruction transmitted by the first user 
network station, and to direct payment of the deter- 
mined amount of the bill based upon the transmitted 
instruction to pay that bill. The pay instruction and the 
determined amount may be transmitted from either the 40 
user or biller network station in a single or separate 
communications, or respectively from the user and biller 
network stations. 

[0017] Preferably, a database stores bill availability 
information identifying available bills of the different bill- 45 
ers for the different users, and the central network sta- 
tion is operable to transmit the bill availability 
information to the user network stations. The bill availa- 
bility information may beneficially include the amount of 
each of the identified bills. If so desired, the availability so 
information may also include other bill summary infor- 
mation, although this is not mandatory. Advantageously, 
the transmitted stored availability information includes 
an indicator which identifies those of the identified avail- 
able bills which require information relevant to determin- 55 
ing the total amount of those bills. The database may 
also be configured to store, typically under the direction 
of the central station processor, any previously deter- 



mined bill amount and the newly determined bill 
amount. 

[0018] In an exemplary operating sequence, the 
central station transmits two or more of the available 
bills to the first user network station. The first user net- 
work station is operable to receive the transmitted bill 
availability information. Normally, this information is dis- 
played by the first user station to the first user. The first 
user station is also operable to select a particular bill 
from the identified bills, typically based upon an input 
from the user. A request for the applicable bill is then 
transmitted by the first user station based upon the 
selection. If the selected bill is a bill of a first biller for the 
first user, the network station associated with the first 
biller operates, in real time, to transmit either a request 
for the information relevant to the bill amount or the 
available bill including a previously computed bill 
amount, as applicable. Preferably, the central station 
also receives a communication, from the first biller sta- 
tion, indicative of the available bill having been 
requested from the first biller. 

[0019] It will also be recognized by those skilled in 
the art, that the invention is easily implemented using 
computer software. More particularly, software can be 
easily programmed, using routine programming skill, 
based upon the description of the invention set forth 
herein and stored on a computer readable storage 
medium which is readable by a computer processor of 
the applicable system component, e.g. a user , a biller 
or a central network station to cause the processor to 
operate such that the particular station operates in the 
manner described above. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0020] In order to facilitate a fuller understanding of 
the present invention, reference is now made to the 
appended drawings. These drawings should not be con- 
strued as limiting the present invention, but are intended 
to be exemplary only. 

Figure 1 is an aggregation model for electronic bill 
presentment. 

Figure 2 is a biller direct model for electronic bill 
presentment 

Figure 3 is an infrastructure diagram of a distributed 
database entity in accordance with the present 
invention. 

Figure 4 is a schematic diagram of an electronic bill 

presentment and payment system in accordance 

with the present invention. 

Figure 5 is a schematic diagram of an electronic 

payment and customer service (EPCS) entity in 

accordance with the present invention. 

Figure 6 is a schematic diagram of the electronic bill 

presentment and payment system shown in Figure 

4, extended to include certain associated directly 

related systems. 
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Figure 7 is a schematic diagram of the electronic bill 
presentment and payment system shown in Figure 
4, extended to include certain associated indirectly 
related systems. 

Figure 8 is a schematic diagram of the electronic bill s 
presentment and payment system shown in Figure 
4, extended to include certain associated customer 
care entities. 

Figure 9 is a schematic diagram of the electronic bill 
presentment and payment system shown in Figure 10 
4, extended to include a centralized customer care 
entity. 

Figure 10 is a flowchart diagram showing initial 
sign-on data and message flows between a user 
entity and a banking entity in the electronic bill pre- is 
sentment and payment system shown in Figure 4. 
Figure 1 1 is a flowchart diagram showing sign-on 
and authentication data and message flows 
between a user entity, a banking entity, and an 
EPCS entity in the electronic bill presentment and 20 
payment system shown in Figure 4. 
Figure 12 is a flowchart diagram showing bill avail- 
ability data and message flows between a user 
entity, a banking entity, and an EPCS entity in the 
electronic bill presentment and payment system 25 
shown in Figure 4. 

Figure 13A is a flowchart diagram showing billing 
entity presentment data and message flows 
between a user entity, a billing entity, and an EPCS 
entity in the electronic bill presentment and pay- 30 
ment system shown in Figure 4. 
Figure 13B is a flowchart diagram showing billing 
aggregator bill presentment data and message 
flows between a user entity, a billing entity, an 
EPCS entity, and an established billing aggregator 35 
in the electronic bill presentment and payment sys- 
tem shown in Figure 4. 

Figure 13C is a flowchart diagram showing alterna- 
tive system bill presentment data and message 
flows between a user entity, an EPCS entity, and an 40 
alternative bill presentment and payment system in 
the electronic bill presentment and payment system 
shown in Figure 4. 

Figure 14 is a flowchart diagram showing bill pay- 
ment data and message flows between a user 45 
entity, an EPCS entity, and a billing entity in the 
electronic bill presentment and payment system 
shown in Rgure 4. 

Figure 15 is a flowchart diagram showing bill remit- 
tance and debiting data and message flows so 
between an EPCS entity and a billing entity and a 
banking entity in the electronic bill presentment and 
payment system shown in Figure 4. 
Figure 1 6 shows an example of a branded interface 
having a sign-on request prompt that includes a 55 
username field and a password field, in accordance 
with the present invention. 
Figure 17 shows an example of a banking entity 



home page, including a "view bills" icon, a "view 
checking account" icon, and a "view Savings 
account" icon, in accordance with the present 
invention. 

Figure 18 shows a first modified banking entity 
home page having a frame presenting new bill 
availability data, in accordance with the present 
invention. 

Rgure 19 shows a second modified banking entity 
home page having a frame presenting detailed bill 
data, in accordance with the present invention. 
Rgure 20 is a flowchart diagram showing customer 
service data and message flows between a central- 
ized customer service center, and an EPCS entity, 
a billing entity, and a banking entity in the electronic 
bill presentment and payment system shown in Fig- 
ure 4. 

Rgure 21 is a flowchart diagram showing bill avail- 
ability data and message flows between a user 
entity, a banking entity, and an EPCS entity in the 
electronic bill presentment and payment system 
shown in Figure 4, modified to allow dynamic 
updating of bill summary information at the EPCS 
entity, in accordance with the present invention. 
Rgure 22A shows a modified banking entity home 
page having a frame presenting new bill availability 
data for a subscriber, with certain data available 
from the biller only after a meter reading is fur- 
nished by the subscriber in accordance with the 
present invention. 

Rgure 22B shows another modified banking entity 
home page having a frame presenting new bill 
availability data, including total bill amounts, for a 
subscriber, with certain data available from the 
biller only after a meter reading is furnished by the 
subscriber in accordance with the present inven- 
tion. 

Figure 23A is a flowchart diagram showing billing 
entity presentment data after receipt of a meter 
reading from the subscriber and message flows 
between a user entity, a billing entity and an EPCS 
entity in the electronic bill presentment and pay- 
ment system shown in Figure 4 for a subscriber, 
with bill summary information being dynamically 
updated at the EPCS, in accordance with the 
present invention. 

Rgure 23B is a flowchart diagram showing billing 
entity presentment data after receipt of a message 
indicating a portion of an originally presented bill is 
disputed by the subscriber and message flows 
between a user entity, a billing entity and an EPCS 
entity in the electronic bill presentment and pay- 
ment system shown in Figure 4 for a subscriber, 
with bill summary information being dynamically 
updated at the EPCS, in accordance with the 
present invention. 

Rgure 24A shows another modified banking entity 
home page having a billing entity frame presenting 
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detailed bill data to a first subscriber after the sub- 
scriber has provided a meter reading, in accord- 
ance with the present invention. 
Figure 24B shows another modified banking entity 
home page having a billing entity frame presenting 
detailed bill data which can be revised to reflect dis- 
puted portions of the bill, in accordance with the 
present invention. 

Figure 24C shows the modified banking entity 
home page of Figured 24B having a billing entity 
frame presenting modified detailed bill data indicat- 
ing that a portion of the bill is disputed, in accord- 
ance with the present invention. 

DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT 

[0021] Referring to Figure 3, there is shown an 
infrastructure diagram of a distributed database entity 
30 in accordance with the present invention. The distrib- 
uted database entity 30 comprises a database compo- 
nent 32 and a plurality of message interfaces 34-40 for 
facilitating communication between the database com- 
ponent 32 and other distributed database entities and 
system components. The database component 32 typi- 
cally contains data that is controlled or "owned" by the 
controller or "owner* of the distributed database entity 
30. For example, if the distributed database entity 30 is 
owned by a financial institution (Fl) such as a bank, then 
the database component 32 could contain information 
such as checking and savings account balances. It 
should be noted, however, that the database compo- 
nent 32 can also contain data from other distributed 
database entities and system components, as will be 
described in detail below. 

[0022] The plurality of message interfaces 34-40 
includes an internal message interface 34, an external 
message interface 36, a partner message interface 38, 
and a customer care message interface 40. The internal 
message interface 34 defines messages that are used 
to communicate and query data between the given dis- 
tributed database entity 30 and other distributed data- 
base entities, or other system components having an 
internal message interface. For example, in a bill pre- 
sentment and payment system, communication 
between a banking entity and a billing entity may be 
required. The external message interface 36 defines 
messages that are used to communicate and query 
data between the given distributed database entity 30 
and any existing system(s) that are directly related to 
the given distributed database entity 30. For example, 
an Fl such as a bank can have an existing direct deposit 
account (DDA) system. The partner message interface 
38 defines messages that are used to communicate and 
query data between the given distributed database 
entity 30 and any existing system(s) that are indirectly 
related to the given distributed database entity 30. For 
example, in a bill presentment and payment system, 



communication with an established billing aggregator 
may be necessary to satisfy customer demands. The 
customer care message interface 40 defines messages 
that are used to communicate and query data between 

5 the given distributed database entity 30 and a customer 
care entity. For example, in a bill presentment and pay- 
ment system, a billing entity may allow a third party to 
access bill data in order to provide feedback to bill cus- 
tomers. It should be noted that all of the above - 

to described interfaces will be described in greater detail 
below. 

[0023] Referring to Figure 4, there is shown a sche- 
matic diagram of a versatile electronic bill presentment 
and payment system 50 in accordance with the present 

15 invention. The system 50 comprises a user entity 52, a 
banking entity 54, a billing entity 56, and an electronic 
payment and customer service (EPCS) entity 58. For 
purposes of this detailed description, the user entity 52, 
the banking entity 54, the billing entity 56, and the EPCS 

20 entity 58 are each distributed database entities 30 as 
defined above. Thus, the user entity 52, the banking 
entity 54, the billing entity 56, and the EPCS entity 58 
each has a database component 32, an internal mes- 
sage interface 34, an external message interface 36, a 

25 partner message interface 38, and a customer care 
message interface 40. It should be noted, however, that 
the user entity 52, the banking entity 54, the billing entity 
56, and the EPCS entity 58 are not required to have a 
database component 32, an internal message interface 

30 34, an external message interface 36, a partner mes- 
sage interface 38, and a customer care message inter- 
face 40. That is, the user entity 52, the banking entity 
54, the billing entity 56, and the EPCS entity 58 are only 
required to have an internal message interface 34 so 

35 that communications can take place between ^each 
entity. 

[0024] At this point it should be noted that, although 
only a single user entity 52, banking entity 54, billing 
entity 56, and EPCS entity 58 is shown in the system 

40 50, it is common to have a plurality of such entities in an 
actual versatile electronic bill presentment and payment 
system in accordance with the present invention. 
[0025] As previously described, an internal mes- 
sage interface 34 defines messages that are used to 

45 communicate and query data between distributed data- 
base entities. Thus, since the user entity 52, the bank- 
ing entity 54, the billing entity 56, and the EPCS entity 
58 are all distributed database entities, they all commu- 
nicate through internal message interfaces 34. The 

so communications are performed over interconnections 
60, which can be electrical wire, optical fiber, or micro- 
wave-based interconnections. 

[0026] At this point it should be noted that each 
internal message interface 34, as well as each external 
55 message interface 36, partner message interface 38, 
and customer care message interface 40, can be imple- 
mented using any number of existing message-based 
communication systems such as, for example, a TCP/IP 
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message-based communication system running on the 
infrastructure of the internet. Alternatively, the internal 
message interfaces 34, the external message interfaces 
36, the partner message interfaces 38, and the cus- 
tomer care message interfaces 40 could be imple- 
mented with proprietary messaging software on a 
private network or intranet. It should also be noted that 
there are no requirements as to the nature of the mes- 
saging protocol, or any middleware used to support the 
messaging. 

[0027] The user entity 52 is typically a personal 
computer (PC) that is directly connected to the system 
50, or is connected to the system 50 through a network 
server. Thus, the database component 32 associated 
with the user entity 52 can be located on the PC (e.g., a 
traditional "fat" client), or on the network server (e.g., an 
HTML browser client). It should be noted that the data- 
base component 32 associated with the user entity 52 
can also be located in one of the other distributed data- 
base entities, which can download data to the user 
entity 52 (e.g., a Java client). It should also be noted that 
the database component 32 associated with the user 
entity 52 can be distributed among all three of the 
above-listed locations, owing to the distributed nature of 
each database component 32. Thus, each database 
component 32 should not be thought of as a single, 
monolithic database. Rather, each database compo- 
nent 32 is better described as a distributed repository of 
data categorized by the entity that "owns" the data. 
[0028] Wherever it is located, the database compo- 
nent 32 associated with the user entity 52 stores data 
that is related to the type of user interface (U I) that is 
being presented to a subscriber of the system 50. For 
example, the database component 32 associated with 
the user entity 52 can store data that is related to the 
particular type of presentation technology being used 
(e.g., a "fat" client, an HTML browser client, or a Java 
client), a specific application, or a particular version. 
The database component 32 associated with the user 
entity 52 can also store data that is related to a particu- 
lar computing session such as, for example, the exist- 
ence of a computing session and/or the duration of a 
computing session. The database component 32 asso- 
ciated with the user entity 52 can further store sub- 
scriber authentication data, which is described in detail 
below. 

[0029] The main function of the user entity 52 is to 
build a Ul using data obtained from the other distributed 
database entities, and then present the Ul to a sub- 
scriber of the system 50. The presentation of the Ul to a 
subscriber is dependent upon the particular type of 
presentation technology being used (e.g., a "fat" client, 
an HTML browser client, or a Java client). For example, 
a Ul for a Java client requires that presentation data be 
downloaded from one of the other distributed database 
entities. 

[0030] Other functions of the user entity 52 include 
storing certain data locally so as to facilitate off-line edit- 



ing and viewing, maintaining a state in a connectionless 
environment (e.g., an HTTP environment), and sensing 
the availability of software updates and managing their 
subsequent application. All of these functions depend 

5 on the nature of the client (e.g., a "fat" client, an HTML 
browser client, or a Java client). As previously indicated, 
another function of the user entity 52 includes storing 
subscriber authentication data (e.g., a security ticket) 
that is used to gain access to other distributed database 

to entities in the system 50. 

[0031] The banking entity 54, which is typically an 
Fl such as, for example, a bank, is generally viewed as 
a primary point of presence for a subscriber to the sys- 
tem 50, typically providing an appearance of aggrega- 

15 tion to the subscriber. This view is held primarily due to 
the trust that consumers typically place in a bank brand, 
and the fact that bank customers who already bank 
online are also likely to want to receive bills online. 
Thus, in the following discussion, the banking entity 54 

20 is assumed to be the aggregator of the system 50. It 
should be noted, however, that any one of the other enti- 
ties could also be the aggregator of the system 50 in 
accordance with the present invention. There are sev- 
eral factors which can be used to determine aggregator 

25 status such as, for example, market clout. 

[0032] The banking entity 54 typically gains access 
to the system 50 through a network server. Thus, the 
database component 32 associated with the banking 
entity 54 can be located in the network server. It should 

30 be noted that the database component 32 associated 
with the banking entity 54 can also be located in a sys- 
tem associated with the banking entity 54 such as, for 
example, a DDA system. Such a DDA system could be 
accessed through the external message interface 36 of 

35 the banking entity 54, as described in detail below. It 
should further be noted that the database component 
32 associated with the banking entity 54 can also be 
located in one of the other distributed database entities, 
or be distributed among many of the above-mentioned 

40 locations, owing to the distributed nature of each data- 
base component 32. 

[0033] Wherever it is located, the database compo- 
nent 32 associated with the banking entity 54 stores 
bank-specific subscriber profile data profile such as, for 

45 example, subscriber names and addresses and sub- 
scriber account numbers. The database component 32 
associated with the banking entity 54 can also store 
account information such as, for example, static 
account information (e.g., lease rate, principle), and 

so dynamic account information (e.g., balance). The data- 
base component 32 associated with the banking entity 
54 can further store profile data specifically associated 
with the Fl such as, for example, graphics, business 
rules, banking-related transaction histories, and aggre- 

55 gation relationships such as those between the Fl and 
billers. 

[0034] Since it is likely that the system 50 will be 
used with existing banking systems such as, for exam- 
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pie, an existing DDA system, one of the main functions 
of the banking entity 54 is the continuation of current 
banking and bill payment functionality including the 
maintaining of customer profiles and already existing 
interfaces. In its role as aggregator, the banking entity 
54 also provides data to the user entity 52 to be used for 
the creation of a navigation portion of a Ul. For an HTML 
browser client, this data would be used to create a nav- 
igation frame, but not a content specific frame. It should 
be noted that the banking entity 54 can also provide 
data to the user entity 52 to be used for the creation of a 
Ul for traditional banking and bill payment. 
[0035] Since the banking entity 54 is generally 
viewed as the primary point of presence for a subscriber 
to the system 50, the banking entity 54 also functions as 
the likely, but not exclusive, entry point for subscriber 
sign-on. Thus, the banking entity 54 typically controls 
the sign-on and authentication procedures for subscrib- 
ers through the user entity 52. It should be noted that 
the banking entity 54 typically works in conjunction with 
the EPCS entity 58 in controlling the authentication pro- 
cedure, as described in detail below. 
[0036] Another function of the banking entity 54 
includes tracking bank related events and storing them 
in an event tracking database, which is typically associ- 
ated with the EPCS entity 58, as also described in detail 
below. 

[0037] The billing entity 56 is typically a biller such 
as, for example, a utility company. The billing entity 56 
typically gains access to the system 50 through a net- 
work server. Thus, the database component 32 associ- 
ated with the billing entity 56 can be located in the 
network server. It should be noted that the database 
component 32 associated with the billing entity 56 can 
also be located in a system associated with the billing 
entity 56 such as, for example, a legacy billing system. 
Such a legacy billing system could be accessed through 
the external message interface 36 of the billing entity 
56, as described in detail below. It should further be 
noted that the database component 32 associated with 
the billing entity 56 can also be located in one of the 
other distributed database entities, or be distributed 
among many of the above-mentioned locations, owing 
to the distributed nature of each database component 
32. 

[0038] Wherever it is located, the database compo- 
nent 32 associated with the billing entity 56 stores biller- 
specific subscriber profile data such as, for example, 
subscriber names and addresses and subscriber 
account numbers and types (e.g., business vs. residen- 
tial phone line). The database component 32 associ- 
ated with the billing entity 56 also stores billing data for 
use by the user entity 52 in building the Ul for the sub- 
scriber. The billing data can Include bill availability data, 
detailed billing data, ads and other cross-sale displays 
and links, and bill payment terms and conditions. 
[0039] The database component 32 associated 
with the billing entity 56 can also store biller transaction 



history such as, for example, bill data manipulation 
(e.g., viewing, searching, sorting), and cross-sell 
events. The database component 32 associated with 
the billing entity 56 can further store biller profile data 

5 such as, for example, graphics, business rules, and 
relationships with aggregators such as banks. 
[0040] The main function of the billing entity 56 is to 
provide billing data to the user entity 52 for use in creat- 
ing the Ul for the subscriber. The billing entity 56 also 

10 provides bill availability data to an aggregator database, 
whether it is located in the banking entity 54, the EPCS 
entity 58, or another entity, to provide notice of bill avail- 
ability to subscribers. The billing entity 56 can also 
access legacy billing systems through the external mes- 

75 sage interface 36 of the billing entity 56, as indicated 
above. 

[0041] Another function of the billing entity 56 
includes tracking biller-related events and storing them 
in an event tracking database, which is typically associ- 
20 ated with the EPCS entity 58, as described in detail 
below. 

[0042] The EPCS entity 58 can generally be 
described in terms of a data processing system 70, 
such as shown in Figure 5. The data processing system 

25 70 preferably comprises at least one processor (P) 72, 
memory (M) 74, and input/output (I/O) interface 76, 
which are connected to each other by a bus 78, for 
implementing the functions of the EPCS entity 58, as 
described in detail below. 

30 [0043] Referring again to Figure 4, the EPCS entity 
58 typically gains access to the system 50 through a 
network server. Thus, the database component 32 
associated with the EPCS entity 58 can be located in 
the network server. It should be noted that the database 

35 component 32 associated with the EPCS entity 58 can 
also be located in a system associated with the EPCS 
entity 58 such as, for example, a legacy aggregating 
system. Such a legacy aggregating system could be 
accessed through the external message interface 36 of 

40 the EPCS entity 58, as described in detail below. It 
should further be noted that the database component 
32 associated with the EPCS entity 58 can also be 
located in one of the other distributed database entities, 
or be distributed among many of the above-mentioned 

45 locations, owing to the distributed nature of each data- 
base component 32. 

[0044] Wherever it is located, the database compo- 
nent 32 associated with the EPCS entity 58 stores bill 
payment-specific subscriber profile data such as, for 

so example, subscriber names and addresses, subscriber 
ODA account numbers, and subscriber credit ratings. 
The database component 32 associated with the EPCS 
entity 58 also stores bill payment warehouse data such 
as, for example, user-specific payees, single occurrence 

55 payments, and recurring payments/models. 

[0045] As previously described, both the banking 
entity 54 and the billing entity 56 track and store events 
in an event tracking database. This event tracking data- 
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base is typically located in the database component 32 
associated with the EPCS entity 58. The event tracking 
data that is stored typically comprises event summaries 
and links to other databases, perhaps residing at other 
entities, which provide event details and/or an audit trail. 
[0046] The database component 32 associated 
with the EPCS entity 58 also stores bill payment trans- 
action histories, and system subscriber profile data 
such as, for example, metadata about subscribers and 
metadata about subscribers' relationships to other enti- 
ties (e.g., a list of billers that a subscriber has enabled). 
The database component 32 associated with the EPCS 
entity 58 further stores billing-related profile information 
on the system aggregator and billers such as, for exam- 
ple, metadata about billing arrangements (e.g., flat rate, 
per subscriber, event-driven, etc.), and aggregation 
data such as, for example, new bill availability and mes- 
sages or special announcements available from the bill- 
ing entity 56. The database component 32 associated 
with the EPCS entity 58 still further stores security data 
such as, for example, required sign-on information and 
macro- level authorizations. The database component 
32 associated with the EPCS entity 58 additionally 
stores customer service data such as, for example, 
FAQ's, Fl and biller contact information, and problem 
resolution data. 

[0047] The EPCS entity 58 is the glue that holds the 
distributed database entities together. The EPCS entity 
58 accomplishes this by functioning as an integration 
agent by maintaining bill payment profiles and ware- 
house data, aggregating bill availability and status data 
(but not bill content or presentation), and maintaining an 
event tracking database (or audit trail) that can be 
accessed by all of the database entities. Also, in order to 
facilitate a single point of sign-on, the EPCS entity 58 
functions as the authentication gate keeper. This 
doesn't mean to imply that the EPCS entity 58 neces- 
sarily maintains user identification numbers and/or 
passwords: r However; it does imply that the EPCS entity 
58 accepts sign-on requests and doles out authentica- 
tion "tickets" in response, in conjunction with the bank- 
ing entity as described above. 
[0048] It should be noted that, like user identifica- 
tion numbers and passwords, other data elements, like 
event details, may end up being virtually aggregated by 
the EPCS entity 58, but may still physically reside in a 
distributed manner across several of the database enti- 
ties. 

[0049] It should also be noted that the EPCS entity 
58 may also route e-mail messages to and from the var- 
ious database entities, as well as store e-mail mes- 
sages sent to and from the various database entities. 
[0050] As previously described, an internal mes- 
sage interface 34 defines messages that are used to 
communicate and query data between distributed data- 
base entities. As also previously described, each inter- 
nal message interface 34 can be implemented using 
any number of existing message-based communication 



systems, or with proprietary messaging software on a 
private network or intranet. Furthermore, the message 
specification or file format can be either standard (i.e., 
open) or proprietary. With this mind, the following types 

s of messages are examples of messages which may be 
employed to implement an internal message interface 
34 in accordance with the present invention. 
[0051] Depending upon the nature of the presenta- 
tion technology being used (e.g., a "fat" client, an HTML 

10 browser client, or a Java client), the user entity 52 may 
need to process an internal message to store a security 
ticket for later use in gaining access to other distributed 
database entities in the system 50. The user entity 52 
may also need to process an internal message to 

15 update any resident software. The user entity 52 may 
further need to process an internal message containing 
various types of information (assuming a push model). 
The user entity 52 may additionally need to process 
internal e-mail messages such as, for example, those 

20 for receiving data from other database entities. 

[0052] The banking entity 54 will process an inter- 
nal message to add/update/delete/retrieve Fl branding 
information, as well as an internal message to 
add/update/delete an entry from a list of billers that have 

25 been aggregated. The banking entity 54 wilt also proc- 
ess an internal message to activate a subscriber for 
home banking via a messaging protocol, which can be 
an existing messaging protocol such as, for example, 
OFX or a batch process. The banking entity 54 will fur- 

30 ther process an internal message to query/update bank 
subscriber profile data for purposes of customer care. 
The banking entity 54 will still further process an internal 
message to query bank transaction history for customer 
care and for linking to the event tracking database. The 

35 banking entity 54 will still further process an internal 
message to retrieve a list of billers available under the Fl 
sponsor umbrella. An alternative to this is to place the 
list of billers available under the Fl sponsor umbrella in 
an aggregation database. However, placing the list of 

40 billers available under the Fl sponsor umbrella allows 
the EPCS entity 58 to tailor the list by Fl sponsor. The 
banking entity 54 will additionally process internal e- 
mail messages such as, for example, those for sending 
data to other database entities, receiving data from 

45 other database entities, and broadcasting data to other 
database entities. 

[0053] The billing entity 56 will process an internal 
message to add/update/delete/retrieve biller branding 
information, as well as an internal message to activate 

so a subscriber for electronic bill presentment via a mes- 
saging protocol, which can be an existing messaging 
protocol such as, for example, OFX or a batch process. 
The billing entity 56 will also process an internal mes- 
sage to retrieve bill availability data, retrieve bill detail 

55 data, and retrieve bill presentation specifications or con- 
tent For example, the retrieved data could be URL links 
to ads and notices, HTML data, or OFX data. The billing 
entity 56 will further process an internal message to 
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query/update biller subscriber profile data for purposes 
of customer care. The billing entity 56 will still further 
process an internal message to query biller transaction 
history for customer care and for linking to the event 
tracking database. The billing entity 56 will additionally 
process internal e-mail messages such as, for example, 
those for sending data to other database entities, 
receiving data from other database entities, and broad- 
casting data to other database entities. 
[0054] The EPCS entity 58 will process internal 
event tracking messages. Such event tracking mes- 
sages are used to gain access to two types of informa- 
tion in the event tracking database: summary data and 
a link to another database entry that can provide more 
detail. Such detail includes subscriber enrollment data, 
subscriber service activation data (e.g., biller, bill pay- 
ment, banking, etc.), sign-on data, bill availability data, 
bill viewed data, bill payment generated data (optionally 
associated with presented bill data), subsequent bill 
payment events data (e.g., submitted, processed, failed, 
cleared, remittance received by biller, etc.), cross-sell 
events data (e.g., ad/offer viewed, ad/offer clicked, prod- 
uct/service purchased), terms & conditions viewed 
data, e-mail created/read/deleted data. 
[0055] The EPCS entity 58 will also process an 
internal messages related to subscriber profile data 
such as, for example, to add/modify/delete/read sub- 
scriber profile data, often as a function of the events 
listed above (e.g., enrollment, activation, etc.). 
[0056] The EPCS entity 58 will also process inter- 
nal security messages. Such internal security mes- 
sages may relate to authentication, which result in the 
EPCS entity 58 issuing a security ticket. It should be 
noted that an authentication request does not have to 
come as a result of a subscriber -surfing'' to the network 
server of the banking entity 54. It may be initiated if a 
subscriber tries to gain access to the billing entity 56, 
and thereby not even contacting the banking entity 54. 
The point being that with a security ticket a subscriber is 
generally allowed to freely traverse any database entity 
in the system 50 without going through repeated sign- 
on procedures. 

[0057] An internal security message may also 
relate to macro-level authorization, wherein a security 
ticket may contain the credentials to allow a subscriber 
access to a particular billing entity, but doesn't address 
micro-level authorization issues such as allowed opera- 
tions. 

[0058] An internal security message may also 
relate to getting a security ticket without authentication. 
Such a message will originate from a trusted party (e.g., 
an Fl performing its own authentication). Therefore, a 
security ticket is provided without performing an authen- 
tication. 

[0059] It should be noted that the use of a security 
ticket enables, but does not mandate, a single sign-on 
procedure. In other words, a database entity such as, 
for example, the billing entity 56 may, for whatever rea- 



son, require additional authentication information. 
[0060] The EPCS entity 58 will further process 
internal messages relating to aggregation data. For 
example, an EPCS entity 58 will process an internal 
5 message to create a link to summary or detailed bill 
information, or to create a link to message, notice, ad, or 
some other kind of non-bill information that is available 
from the billing entity 56. 

[0061] The EPCS entity 58 will still further process 

w an internal message to query/update bill payment trans- 
action history for purposes of customer care. 
[0062] The EPCS entity 58 will additionally process 
internal e-mail messages such as, for example, those 
associated with routing e-mail, picking-up e-mail, and 

is querying and e-mail mailbox. 

[0063] The EPCS entity 58 may also process inter- 
nal messages related to data mining. Such messages 
are handled very carefully with respect to privacy, per- 
haps even providing an ACL or other mechanisms to 

20 ensure privacy. The results of such messages may be 
delivered out of band (e.g., by batch). 
[0064] As previously described, an external mes- 
sage interface 36 defines messages that are used to 
communicate and query data between a given distrib- 

25 uted database entity 30 and any existing system(s) that 
are directly related to the given distributed database 
entity 30. As also previously described, each external 
message interface 36 can be implemented using any 
number of existing message-based communication sys- 

30 terns, or with proprietary messaging software on a pri- 
vate network or intranet. Furthermore, the message 
specification or file format can be either standard (i.e., 
open) or proprietary. 

[0065] Referring to Figure 6, there is shown a sche- 

35 matic diagram of the versatile electronic bill present- 
ment and payment system 50, along with some 
associated directly related systems. The associated 
directly related systems comprise a desktop database 
80, a DDA system 82, a legacy billing system 84, and a 

40 legacy remittance system 86. The communications 
between the various database entities and their associ- 
ated directly related systems are performed over inter- 
connections 88, which can be electrical wire, optical 
fiber, or microwave-based interconnections. 

45 [0066] Depending upon the nature of the presenta- 
tion technology being used (e.g., a fat" client, an HTML 
browser client, or a Java client), the user entity 52 may 
need to process an external message in order to com- 
municate with an existing system such as, for example, 

so the desktop database 80. To support such a legacy sys- 
tem, it may be necessary to implement the external 
message interface 36 of the user entity 52 in the context 
of an existing, and possibly extended, protocol specifi- 
cation, such as Gold, NPC, or OFX. 

55 [0067] The banking entity 54 will process external 
messages to and from an existing system such as, for 
example, the DDA system 82 in order to query and 
update information such as, for example, subscriber 
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profile data, subscriber account data, out-of-band (e.g., 
ATM) account activity, and statement history. It's also 
conceivable that the banking entity 54 would need to 
interface with other banking systems (e.g., stops). Thus, 
the external message interface 36 of the banking entity 
54 is a key feature of the versatile electronic bill present- 
ment and payment system 50. 

[0088] The billing entity 56 will process external 
messages to and from an existing system such as, for 
example, the legacy billing system 84 in order to query 
and update information such as, for example, sub- 
scriber profile data, subscriber account data, account 
activity, and statement history. Most of this data is indus- 
try, if not biller, specific. Thus, the external message 
interface 36 of the billing entity 56 is a key feature of the 
versatile electronic bill presentment and payment sys- 
tem 50. 

[0069] The EPCS entity 58 will process external 
messages to and from an existing system such as, for 
example, the legacy remittance system 86. The legacy 
remittance system 86 could be, for example, ACH, RPR 
RPS, or Direct Send. 

[0070] As previously described, a partner message 
interface 38 defines messages that are used to commu- 
nicate and query data between a given distributed data- 
base entity 30 and any existing system (s) that are 
indirectly related to the given distributed database entity 
30. As also previously described, each partner mes- 
sage interface 38 can be implemented using any 
number of existing message-based communication sys- 
tems, or with proprietary messaging software on a pri- 
vate network or intranet. Furthermore, the message 
specification or file format can be either standard (i.e., 
open) or proprietary. 

[0071] Referring to Figure 7, there is shown a sche- 
matic diagram of the versatile electronic bill present- 
ment and payment system 50, along with some 
associated indirectly related systems. The associated 
indirectly related systems comprise a personal finance 
system 90, a banking system 92, an established billing 
aggregator 94, and an alternative bill presentment and 
payment system 96. The communications between the 
various database entities and their associated indirectly 
related systems are performed over interconnections 
98, which can be electrical wire, optical fiber, or micro- 
wave-based interconnections. 

[0072] Depending upon the nature of the presenta- 
tion technology being used (e.g., a "fat 0 client, an HTML 
browser client, or a Java client), the user entity 52 may 
need to process a partner message in order to commu- 
nicate with a partner such as, for example, the personal 
finance system 90. The personal finance system 90 
could be, for example, a personal financial manager 
(PFM) software package such as, for example, Quicken 
or Money. 

[0073] The banking entity 54 will process partner 
messages to and from a partner such as, for example, 
the banking system 92. 



[0074] The billing entity 56 will process partner 
messages to and from a partner such as, for example, 
the established billing aggregator 94. Such a partner 
relationship may be required if a large group of sub- 

5 scribe rs are using the established billing aggregator 94, 
and thereby have the leverage to demand that ail of their 
bills come through the established billing aggregator 94. 
The established billing aggregator 94 is essentially 
treated as a proxy for the billers that it represents. Thus, 

ro subscribers to the established billing aggregator 94 will 
have equal footing as subscribers to the present system 
50. This means that subscribers to the established bill- 
ing aggregator 94 will receive the same event tracking, 
customer service, and payment processing functionality 

rs as subscribers to present system 50. Of course, to gain 
the additional functionality provided by the present sys- 
tem 50, the established billing aggregator 94, or some- 
one acting on their behalf, will need to provide the same 
programming support that is required of any biller par- 

20 ticipating in the present system 50. 

[0075] To present a bill generated by the estab- 
lished billing aggregator 94, the present system 50 
would, for example, receive bill availability data and the 
URL of a web server of the established billing aggrega- 

25 tor 94, and the billing entity 56 would then point to the 
web server of the established billing aggregator 94 to 
get an HTML presentation of detailed bill data. In this 
scenario, the partner message interface 38 would be 
essentially the same as an internal message interface 

30 34, but possibly with added bulk transfer capability. 
[0076] The EPCS entity 58 will process partner 
messages to and from a partner such as, for example, 
the alternative bill presentment and payment system 96. 
Such a partner relationship may be required if a billing 

35 entity 56 has a subscriber base that is split between 
using the present system 50 and the alternative bill pre- 
sentment and payment system 96. In such a scenario, 
the present system 50 could function as a billing aggre- 
gator for the alternative bill presentment and payment 

40 system 96, and vice-versa. However, the alternative bill 
presentment and payment system 96 and its subscrib- 
ers would not receive any of the benefits of the messag- 
ing functionality provided by the present system 50. 
Only the minimum amount of functionality would be pro- 

45 vided. That is, the partner message interface 38 would 
only provide what is required to present bills through the 
alternative bill presentment and payment system 96, 
and not offer any of the advantages provided by the 
present system 50. The goal being to have the billing 

so entity 56 encourage all of its subscribers to access bills 
through the present system 50. 
[0077] It should be noted that the EPCS entity 58 
will typically require the capabilities of a billing entity 56 
in order to present bills to and from the alternative bill 

55 presentment and payment system 96. 

[0078] As previously described, a customer care 
message interface 40 defines messages that are used 
to communicate and query data between a given distrib- 
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uted database entity 30 and a customer care entity. As 
also previously described, each customer care mes- 
sage interface 40 can be implemented using any 
number of existing message-based communication sys- 
tems, or with proprietary messaging software on a pri- 5 
vate network or intranet Furthermore, the message 
specification or file format can be either standard (i.e., 
open) or proprietary. 

[0079] Referring to Figure 8, there is shown a sche- 
matic diagram of the versatile electronic bill present- 10 
ment and payment system 50, along with some 
associated customer care entities. The associated cus- 
tomer care entities comprise a user entity self service 
center 100, a banking entity customer service center 
1 02, a billing entity customer service center 1 04, and an is 
EPCS customer service center 106. The communica- 
tions between the various database entities and their 
associated customer care entities are performed over 
interconnections 108, which can be electrical wire, opti- 
cal fiber, or microwave-based interconnections. 20 
[0080] Depending upon the nature of the presenta- 
tion technology being used (e.g., a "fat" client, an HTML 
browser client, or a Java client), the user entity 52 may 
need to process a customer care message in order to 
communicate with a customer care entity such as, for 25 
example, the user entity self service center 100. The 
user entity seif service center 100 could v be, for exam- 
ple, a self service diagnostic tool. 
[0081] The banking entity 54 will process customer 
care messages from a customer care entity such as, for 30 
example, the banking entity customer service center 
1 02. A customer care message may be a request for 
data or a request to modify existing data. The banking 
entity 54 will process such customer care messages by 
providing the requested data or providing a confirmation 35 
that the existing data has been modified, respectively, to 
the banking entity customer service center 102. The 
banking entity customer service center 1 02 could be, for 
example, a third party telemarketing group that is 
allowed access to banking and overall system data in 40 
order to provide feedback to system subscribers. 
[0082] The billing entity 56 will process customer 
care messages from a customer care entity such as, for 
example, the billing entity customer service center 104. 
A customer care message may be a request for data or 45 
a request to modify existing data. The billing entity 56 
will process such customer care messages by providing 
the requested data or providing a confirmation that the 
existing data has been modified, respectively, to the bill- 
ing entity customer service center 1 04. The billing entity so 
customer service center 104 could be, for example, a 
third party telemarketing group that is allowed access to 
billing and overall system data in order to provide feed- 
back to system subscribers. 

[0083] The EPCS entity 58 will process customer ss 
care messages from a customer care entity such as, for 
example, the EPCS entity customer service center 1 06. 
A customer care message may be a request for data or 



20 

a request to modify existing data. The EPCS entity 58 
will process such customer care messages by providing 
the requested data or providing a confirmation that the 
existing data has been modified, respectively, to the 
EPCS entity customer service center 1 06. The EPCS 
entity customer service center 1 06 could be, for exam- 
ple, a third party telemarketing group that is allowed 
access to event and overall system data in order to pro- 
vide feedback to system subscribers. 
[0084] It should be noted that all of the customer 
care entities described above could be consolidated 
into a centralized customer service center 110, as 
shown in Figure 9. In such a scenario, each of the data- 
base entities would process customer care messages 
to and from the centralized customer service center 110 
similar to as described above. The communications 
between the various database entities and the central- 
ized customer service center 110 would be performed 
over interconnections 112, which can be electrical wire, 
optical fiber, or microwave-based interconnections. 
[0085] Referring to Figures 1 0-1 5, there are shown 
flowchart diagrams of data and message flows between 
the various entities within the system 50. These flow- 
chart diagrams assume that the user entity 52 is an 
HTML browser client, the banking entity 54 is the pri- 
mary point of presence for a subscriber to the system 
50, the billing entity 56 controls bill presentment, and 
the EPCS entity 58 controls bill payment. 
[0086] In Figure 10, a subscriber at the user entity 
52 accesses the web site of the banking entity 54 in step 
200. In return, the banking entity 54 presents a branded 
interface to the user entity 52, including a sign-on 
request prompt in step 202. Figure 16 shows an exam- 
ple of such a branded interface 120, wherein the sign- 
on request prompt includes a username field 122 and a 
password field 124. 

[0087] In Figure 11, the user entity 52 submits a 
sign-on request with authentication credentials in steps 
204. The banking entity 54 messages the EPCS entity 
58 with the authentication credentials of the subscriber 
and the event is logged in step 206. The EPCS entity 58 
provides a security ticket to the banking entity 54 in step 
208. The banking entity 54 delivers the security ticket to 
the user entity 52 and presents its "home page" to user 
entity 52 in step 210. Figure 17 shows an example of 
such a home page 130, which includes a "view bills" 
icon 132, a "view checking account" icon 134, and a 
"view savings account" icon 136. 
[0088] It should be noted that either the EPCS 
entity 58 or the banking entity 54 could perform the 
authentication procedure, but in either case the event is 
still logged in the event tracking database. 
[0089] In Figure 1 2, the subscriber selects the "view 
bills" icon 132 in step 212. Tiie banking entity 54 mes- 
sages the EPCS entity 58 with an aggregation data 
request and the event is logged in step 214. The EPCS 
entity 5B presents aggregation data of new bill availabil- 
ity to user entity 52 in step 216. Figure 18 shows a first 
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modified home page 140 having an EPCS entity frame 
142 presenting the new bill availability data, which 
includes an "electric bill" icon 144, a "gas bill" icon 146, 
a "phone bill" icon 148, a "cable bill" icon 150, a "credit 
card bill" icon 152, and an "all bills" icon 154 which 
allows all bills to be presented simultaneously, albeit in 
separate frames. 

[0090] In Figure 13A, the subscriber selects the 
"gas bill" icon 146 and is linked to the billing entity 56 
along with the security ticket in step 218. The billing 
entity 56 messages the EPCS entity 58 to log the "view 
bill" request event in step 220. The billing entity 56 
presents detailed bill data to the user entity 52 in step 
222. Figure 19 shows a second modified home page 
160 having a billing entity frame 162 presenting the 
detailed bill data, which includes the subscriber name, 
subscriber address, account number, usage, and cost, 
and a "pay bill" icon 164. 

[0091] In Figure 14, the subscriber selects the "pay 
bill" icon 164 and messages the EPS entity 58 with a 
forward dated pay bill request so the event is logged in 
step 224. The EPS entity 58 messages the billing entity 
56 with a pay bill request notification along with a bill 
identification number in step 226. 
[0092] In Figure 15, the EPS posts a debit with the 
banking entity 54 and the event is logged in step 228. 
The EPS entity 58 then remits a payment to the billing 
entity 56 and the event is logged in step 230. 
[0093] Rgure 13Bcan be substituted for Figure 13A 
in the above-described sequence of flowchart diagrams 
to show how detailed bill data can be provided by the 
established billing aggregator 94 thru the partner mes- 
sage interface 38 of the billing entity 56. In Figure 13B, 
the subscriber again selects the "gas bill" icon 146 and 
is linked to the billing entity 56 along with the security 
ticket in step 232. The billing entity 56 again messages 
the EPCS entity 58 to log the "view bill" request event in 
step 234. However, in this case, detailed bill data is 
available only from the established billing aggregator 
94. Thus, the billing entity 56 accesses the established 
billing aggregator 94 through its partner message inter- 
face 38 in step 236. In response, the established billing 
aggregator 94 provides detailed bill data to the billing 
entity 56 in step 238. The billing entity 56 then presents 
the detailed bill data to the user entity 52 in step 240. 
[0094] It should be noted that, in an alternative 
embodiment, the established billing aggregator 94 
could present the detailed bill data directly to the user 
entity 52. 

[0095] Figure 13C can be substituted for Figure 
13A in the above-described sequence of flowchart dia- 
grams to show how detailed bill data can be provided by 
the alternative bill presentment and payment system 96 
thru the partner message interface 38 of the EPCS 
entity 58. In Figure 13C, the subscriber selects the "gas 
bill" icon 146 and is linked back to the EPCS entity 58 
along with the security ticket and the event is logged in 
step 242. In this case, detailed bill data is available only 



from the alternative bill presentment and payment sys- 
tem 96. Thus, the EPCS entity 58 accesses the alterna- 
tive bill presentment and payment system 96 through its 
partner message interface 38 in step 244. In response, 

5 the alternative bill presentment and payment system 96 
provides detailed bill data to the EPCS entity 58 in step 
246. The EPCS entity 58 then presents the detailed bill 
data to the user entity 52 in step 248. 
[0096] It should be noted that, as previously 

10 described, the EPCS entity 58 will typically require the 
capabilities of a billing entity 56 in order to present bills 
to and from the alternative bill presentment and pay- 
ment system 96. Alternatively, it should be noted that 
detailed bill data can be provided by the alternative bill 

is presentment and payment system 96 thru the partner 
message interface 38 of the billing entity 56 in a manner 
similar to that as described in Figure 13B. 
[0097] Referring to Figure 20, there is shown a flow- 
chart diagram of data and message flows between the 

20 centralized customer service center 1 10 and the various 
entities within the system 50. A subscriber 1 70 contacts 
the centralized customer service center 110 regarding a 
bill payment in step 250. The centralized customer serv- 
ice center 110 accesses the event tracking database in 

25 the EPCS entity 58 to see if a view bill, pay bill, remit 
payment, or debit posting event has been logged in step 
252. If more detailed information regarding, for exam- 
ple, the posting of a debit for a bill, the centralized cus- 
tomer service center 110 can access the database 

30 component 32 associated with the banking entity 54, as 
shown in step 254. Similarly, if more detailed informa- 
tion regarding, for example, the remitting of a payment 
for a bill, the centralized customer service center 110 
can access the database component 32 associated with 

35 the billing entity 56, as shown in step 256. It should be 
noted that, although not shown, the EPCS entity 58 can 
log all of the above-described accesses performed by 
centralized customer service center 1 1 0. 
[0098] As is apparent from the foregoing descrip- 

40 tion, the system 50 allows a subscriber to interact 
directly with individual billers while retaining the benefits 
of interacting with a single aggregator such as, for 
example, the ability to retain a single authentication and 
log-in procedure and a common bill presentation frame- 

45 work. The system 50 also allows a subscriber to retain 
the benefits of interacting with a single aggregator while 
allowing the billers and banks to retain certain prefer- 
ences such as, for example, the ability to retain control 
of subscriber-related data and a communication chan- 

so nel with each subscriber. 

[0099] As discussed above with reference to Fig- 
ures 14 and 15, when, after reviewing billing informa- 
tion, detailed or otherwise, at the biller entity site, the 
user selects "pay bill", the user is directed to the EPCS 

55 which communicates with the applicable billing and 
banking entities to process the payment. To perform this 
function, the database component 32 associated with 
the EPCS entity 58 must be kept aware of the total 



12 



23 



EP 1 083 532 A2 



24 



amount of each available bill for a user. Accordingly, 
each billing entity must provide bill summary informa- 
tion, including at least the total bill amount, for each 
available bill to the aggregator database, which is pref- 
erably but not necessarily located at the EPCS entity, as 
has been previously discussed. Thus, the database 
component 32 of the EPCS entity 58 stores bill sum- 
mary information for each available bill for each user 
which is accessed and used by the EPCS to process 
payment responsive to the receipt of the user's "pay bill- 
request message. 

[0100] As will be understood, if the total bill amount 
stored in the database component 32 of the EPCS 
entity 58 does not match the total bill amount presented 
to the user by the billing entity, serious payment prob- 
lems could arise. For example, if in reviewing the 
detailed electronic bill information maintained by the bill- 
ing entity, the user is allowed to dispute a charge and to 
have the disputed charge removed from the bill pending 
resolution of the dispute, the bill may be adjusted by the 
billing entity while the user remains on-line. If this 
adjustment to the total bill amount is not conveyed to the 
EPCS in real time, should the user select "pay bill" dur- 
ing the session, the total bill amount, as reflected at the 
billing entity, will be less than the total bill amount stored 
in the database component 32 of the EPCS entity 58. 
Thus, the EPCS would process the requested payment 
in the wrong amount. 

[0101] Further, some billers, particularly utility com- 
panies, are now offering discounts to customers who 
perform, and provide to the company, monthly meter 
readings. The utility company generates the customer's 
bill based upon the meter reading provided by the cus- 
tomer. Receiving this information via a digital communi- 
cation, such as an Internet communication, facilitates 
the processing of the information by the company while 
the user remains on-line. Hence, the user can provide a 
meter reading, the billing entity can generate a bill 
based upon the meter reading, and the detailed bill 
information can be presented to the user all in a single 
on-line session between the user and the billing entity. If 
this generated total bill amount is not conveyed to the 
EPCS in real time, the user either would not be allowed 
to direct payment of the bill by selecting "pay bill" during 
the on-line session, or would have the processing of its 
payment directive delayed, since the EPCS would not 
be privy to the total bill amount generated by the billing 
entity at the time of the payment request. 
[0102] Figure 21 depicts the message flow in an 
alternative electronic billing system which is capable of 
updating bill summary information stored at the EPCS 
in real time, and hence providing dynamically updatea- 
ble electronic bill summary information to a subscriber. 
The system ensures consistency between bill informa- 
tion at the EPCS and at the biller. This feature can be 
particularly important in facilitating the electronic pre- 
sentment and payment of bills. 
[0103] As shown, the subscriber selects the "view 



bills" icon 1132 in step 1212. The banking entity 54 
messages the EPCS entity 58 with an aggregation data 
request and the event is logged in step 1214. The EPCS 
entity 58 presents aggregation data of new bill availabil- 

5 ity to user entity 52 in step 1 21 6. 

[0104] An EPCS entity frame 1 140A presenting the 
new bill availability data for a subscriber is shown in Fig- 
ure 22A. Figure 22A is similar to Figure 1 8, except that 
a notification is provided to the user that the electric and 

10 gas bills require a meter reading. More particularly, the 
available bills shown on screen 1 140A include an "elec- 
tric bill" icon 1 144, a "gas bill" icon 1 146, a "phone bill" 
icon 1 1 48A, a "cable bill" icon 1 1 50A, a "credit card bill- 
icon 1 152A, and an "all bills" icon 1 154 which allows all 

is bills to be presented simultaneously, albeit in separate 
frames. The electric and gas bills are shown with an 
associated notation reminding the subscriber that 
he/she must provide the applicable meter reading in 
order to obtain these bills from the biller 56. 

20 [0105] Alternatively, an EPCS entity frame 1140B 
could be used to present the new bill availability data for 
a subscriber as shown in Figure 22B. Figure 22B is sim- 
ilar to Figure 22A except that summary information, 
including the total bill amount, is provided for some of 

25 the available bills. More particularly, the available bills 
shown with the total bill amount on screen 1140B 
include a "phone bill" icon 1148B, a "cable biir icon 
1150B, and a "credit card bill" icon 1152B. Each of 
these bills also has a "pay bill" icon 1 155, which allows 

30 the user to pay that bill directly from the screen 1 1408 
by simply clicking-on the icon for the bill. 
[0106] In Figure 23A, which is similar to Figure 13A, 
the subscriber selects the "gas bill" icon 1146 from 
screen 1 140A or 1 MOB and is linked to the billing entity 

35 56 along with the security ticket in step 121 8A. The bill- 
ing entity 56 messages the EPCS entity 58 to log the 
"view bill" request event in step 1220A. The billing entity 
56 first presents a query requesting the gas meter read- 
ing from the user entity 52 in step 1221 A. The user 

40 entity 52 responds to the request in step 1 222A by mes- 
saging the gas meter reading to the billing entity 56. The 
billing entity 56 processes the gas meter reading to gen- 
erate the detailed bill data in real time while the user 
entity remains on-line. 

45 [0107] The generated detailed bill data is presented 
to the user entity 52 in step 1223A. As shown in Figure 
24A, the generated detailed bill information is presented 
on a home page 1160A, having a billing entity frame 
1162A which includes the generated detailed gas bill 

so data for the subscriber. The home page 1 1 60A includes, 
within frame 1162A, the subscriber name, subscriber 
address, account number, the total cost or amount of 
the bill, a "pay bill" icon 1164A and a "home" icon 
1167A. 

55 [0108] In one alternative operational sequence, the 
billing entity 56 messages the total amount of the gener- 
ated gas bill to the EPCS 58 in real time while the user 
entity 52 remains on-line in step 1224A. The detailed 
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gas bill data is stored in the database component 32 of 
the billing entity 56. The total gas bill amount is stored in 
the database component 32 of the EPCS 58. Hence, 
the subscriber can now click on the "pay biH" icon 1 1 64A 
to be hyperlinked back and to transmit a pay request 
message to the EPCS 58. The EPCS will have the gen- 
erated bill amount necessary to proceed with the pay- 
ment, as has been previously described, in accordance 
with the pay instruction. The subscriber can alterna- 
tively click on the "home" icon 1 1 67A to reconnect to the 
EPCS 58 and again view screen 1140A or 1140B. In 
this viewing the screen 1 140A or the screen 1 1 40B, as 
applicable, would be modified so as to reflect the total 
gas bill amount due. 

[0109] More particularly, the modified screen 1 140A 
no longer includes the indication shown in Figure 22A 
that a gas meter reading is required. Rather, the EPCS 
58, responsive to the receipt of the total bill amount and 
in real time, generates a revised screen 1 140A for pres- 
entation to the subscriber which reflects the total gas bill 
amount computed by the billing entity 56 based on the 
gas meter reading provided by the user entity 52. The 
modified screen 1140B also eliminates the indication 
shown in Figure 22B that a gas meter reading is 
required and displays the computed total gas bill 
amount and an associated "pay bill" icon. 
[0110] In a preferred alternative operational 
sequence, user entity 52 rather than billing entity 56 
messages the computed total gas bill amount to the 
EPCS 58. More particularly, after being presented with 
the generated bill, the subscriber clicks on either the 
"pay bill" icon 1 164A or the "home" icon 1167A and is 
hyperlinked back to the EPCS 58. A fat URL is used to 
address the EPCS 58, allowing the generated total bill 
amount to be included in the URL used to hyperlink 
back to the EPCS. Thus, the EPCS 58 receives the gen- 
erated bill amount from the subscriber, either with or 
without an instruction to pay the bill, in real time while 
the user entity 52 remains on-line in step 1224A'. Here 
again, the detailed gas bill data is stored in the database 
component 32 of the billing entity 56 and the total gas 
bill amount is stored, at least temporarily, in the data- 
base component 32 of the EPCS 58. 
[0111] If the subscriber has clicked on the "home" 
icon 1167A, the subscriber can again view screen 
1140A or 1140B. In this viewing the screen 1140A 
would be modified to eliminate the indication shown in 
Figure 22A that a gas meter reading is required. As pre- 
viously discussed, the EPCS responds to the receipt of 
the total bill amount by generating, in real time, a 
revised screen 1 140A for presentation to the subscriber 
which reflects the biller computed total bill amount 
based on the user provided gas meter reading. The 
screen 1 140B is modified to eliminate the indication that 
a gas meter reading is required, as shown in Figure 
22B, and also to display the total gas bill amount and an 
associated "pay bill" icon. 

[0112] In Figure 23B, the subscriber selects the 



"phone bill" icon 1 140A or 1 140B to view the phone bill 
and is linked to the billing entity 56 along with the secu- 
rity ticket in step 1218B. The billing entity 56 messages 
the EPCS entity 58 to log the "view bill" request event in 
5 step 1220B. The billing entity 56 presents the detailed 
bill data, which is stored in the database component 32 
of the billing entity 56, to the user entity 52 in step 
1221B. 

[0113] Turning to Figure 24B, a home page 1160B 
10 has a billing entity frame 1 162B presenting the detailed 
phone bill data to the subscriber. The home page 1160B 
includes, within frame 1162B, the subscriber name, 
subscriber address, account number, a breakout of the 
individual calls being charged 1166A, 1166B and 
75 1 1 66C, and the associated cost of each call, the total bill 
amount 1168, a "pay bill" icon 1164B, a "home" icon 
1167B and respective "dispute" icons 1165A, 1165B 
and 1165C. 

[0114] The subscriber responds to the detailed 
20 phone bill data presented in step 1221B by clicking on 

the dispute icon 1 1 65B. This results in the user entity 52 

messaging the billing entity 56 with an indication that 

the charge for call 1 1 66B is disputed by the subscriber. 

The billing entity 56 processes the dispute message to 
25 remove the disputed charge and to generate revised 

detailed bill data in real time while the user entity 

remains on-line. 

[0115] The generated revised detailed bill data is 
presented to the user entity 52 in step 1223B. As shown 

30 in Figure 24C, the home page 1 1 60B has the billing 
entity frame 1162B updated to present the detailed 
revised phone bill data to the subscriber. The home 
page 1160B therefore now includes, within revised 
frame 1 162B, the breakout of the individual calls being 

35 charged, i.e. calls 1 1 66A and 1 1 66C, with their associ- 
ated cost, and the revised total amount 1 1 68A based on 
only these calls. The revised frame 1 1 62B also reflects 
that the cost of call 1 166B is disputed. 
[0116] In one alternative operational sequence, the 

40 billing entity 56 messages the revised total amount of 
the phone bill to the EPCS 58 in real time, while the user 
entity 52 remains on-line, in step 1224B. The revised 
detailed phone bill data is stored in the database com- 
ponent 32 of the billing entity 56. The revised total 

45 phone bill amount is stored in the database component 
32 of the EPCS 58. Hence, the subscriber can now click 
on the "pay bill" icon 1 164B to be hyperlinked back and 
to transmit a pay request message to the EPCS 58. The 
EPCS has the generated revised bill amount necessary 

so to proceed with the payment in accordance with the 
instruction, as has been previously described. The sub- 
scriber can alternatively click on the "home" icon 1 1 67B 
to reconnect to the EPCS 58 and again view screen 
11 40 A or 1140B, as applicable. In this viewing the 

55 screen 1 1 40A would remain as shown in Figure 22A but 
the screen 1140B would be modified. 
[01 1 7] More particularly, the modified screen 1 1 40B 
displays the revised total phone bill amount. This is 
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accomplished by the EPCS 58, responsive to the 
receipt of the revised total bill amount and in real time, 
generating revised screen 1 1 40B for presentation to the 
subscriber so as to reflect the computed revised total 
gas bill amount. 

[0118] In a preferred alternative operational 
sequence, user entity 52 rather than billing entity 56 
messages the computed revised total phone bill amount 
to the EPCS 58. More particularly, after being presented 
with the generated revised bill, the subscriber clicks on 
either the "pay biir icon 1164B or the "home" icon 
1 1 67B and is hyperlinked back to the EPCS 58. As dis- 
cussed above, a fat URL is used to address the EPCS 
58. This allows the generated revised total bill amount to 
be included in the URL used to hyperlink back to the 
EPCS. Thus, the EPCS 58 receives the generated 
revised bill amount from the subscriber, either with or 
without an instruction to pay the bill, in real time while 
the user entity 52 remains on-line in step 1224B'. Here 
again, the revised detailed phone bill data is stored in 
the database component 32 of the billing entity 56 and 
the revised total phone bill amount is stored, at least 
temporarily, in the database component 32 of the EPCS 
58. 

[0119] If the subscriber has clicked on the "home- 
icon 1167B, the subscriber can again view screen 
1140A or 1140B. In this viewing the screen 1140A is 
unmodified. On the other hand, the screen 1140B is 
modified to display the revised total phone bill amount. 
As previously discussed, this is accomplished by the 
EPCS 58 generating, responsive to the receipt of the 
revised total bill amount and in real time, a revised 
screen 1140B for presentation to the subscriber which 
reflects the biller computed revised total phone bill 
amount. 

[0120] At this point it should be noted that while the 
foregoing detailed description was directed to an elec- 
tronic bill presentment and payment technique, any 
number of system types can employ the distributed 
database entities 30 to facilitate distributed data 
accessing within a network in accordance with the 
present invention. 

[0121] The present invention is not to be limited in 
scope by the specific embodiments described herein. 
Indeed, various modifications of the present invention in 
addition to those described herein, will be apparent to 
those of skill in the art from the foregoing description 
and accompanying drawings. Thus, such modifications 
are intended to fall within the scope of the appended 
claims. 

Claims 

1. An electronic bill payment network, comprising: 

a plurality of user network stations associated 
with a plurality of different users, a first of the 
plurality of user network stations being associ- 



ated with a first of the plurality of different users 
and operable to transmit, in real time, informa- 
tion relevant to an amount of an available bill 
and an instruction to pay the available bill; 

5 a plurality of biller network stations associated 

with a plurality of different billers, a first of the 
plurality of biller network stations being associ- 
ated with a first of the plurality of different billers 
and operable, in real time, to receive the trans - 

10 mitted information and to determine the 

amount of the available bill based upon the 
received information; and 
a central network station operable, in real time, 
to receive the determined amount of the availa- 

15 ble bill and the transmitted pay instruction, and 

to direct payment of the determined amount of 
the available bill based upon the transmitted 
instruction to pay that available bill. 

20 2, A network according to claim 1 , wherein: 

the central network station is further operable 
to transmit bill availability information identify- 
ing a plurality of available bills of the plurality of 

25 different billers for the plurality of different 

users, including at least two of the plurality of 
available bills for the first user; and 
the first user network station is further operable 
to receive the transmitted bill availability infor- 

30 mation, to select the available bill from the iden- 

tified at least two available bills, and to transmit 
a request for the available bill based upon the 
selection. 

35 3. A network according to claim 2, wherein the bill 
availability information identifies available bills with- 
out identifying an amount of each of the bills. 

4. A network according to claim 2, further comprising: 

40 

a database configured to store the bill availabil- 
ity information so as to further identify those of 
the identified available bills which require infor- 
mation relevant to the amount of those identi- 
45 fied available bills. 

5. A network according to claim 4, wherein the data- 
base is further configured to store the determined 
amount. 

50 

6. A network according to claim 1 , wherein the trans- 
mitted information is indicative of a quantity of prod- 
uct used. 

55 7. A network according to claim 6, wherein the trans- 
mitted information is a meter reading. 

8. A network according to claim 1 , wherein the trans- 
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mitted information is indicative of a disputed portion 
of a previously determined amount of the available 
bill. 

9. A network according to claim 1 , wherein: 

the first biller network station is further opera- 
ble, in real time, to transmit the available bill 
including a previously determined amount, and 
the determined amount of the available bill rep- 
resents an adjustment to the previously deter- 
mined amount. 

10. A method of paying electronic bills, comprising the 
steps of: 

transmitting, in real time, information relevant 
to an amount of an available bill, from a first 
network location; 

determining, in real time, the amount of the 
available bill based upon the transmitted infor- 
mation, at a second network location; 
receiving, in real time, the determined amount, 
at the first network location; 
transmitting, in real time, an instruction to pay 
the determined amount, from the first network 
location; 

receiving, in real time, the determined amount 
and the transmitted pay instruction, at a third 
network location; and 

directing payment of the determined amount of 
the available bill based upon the transmitted 
pay instruction, from the third station. 

11. A method according to claim 10, further comprising 
the steps of: 

transmitting, in real time, bill availability infor- 
mation identifying a plurality of available bills of 
a plurality of different billers, from the third net- 
work location; 

selecting, in real time, the available bill from the 
identified plurality of available bills; 
transmitting, in real time, a request for the avail- 
able bill based upon the selection; and 
transmitting, in real time, a request for the rele- 
vant information responsive to the transmitted 
request for the available bill; 
wherein the relevant information includes a 
quantity of product used and is transmitted 
responsive to the transmitted request for rele- 
vant information. 

12. A method according to claim 1 1 , wherein the quan- 
tity of product used is represented by a meter read- 
ing. 

13. A method according to daim 1 0, further comprising 



the steps of: 

transmitting, in real time, bill availability infor- 
mation identifying a plurality of available bills of 
5 a plurality of different billers, from the third net- 

work location; 

selecting, in real time, the available bill from the 
identified plurality of available bills; 
transmitting, in real time, a request for the avail- 
to able bill based upon the selection; and 

transmitting, in real time, the available bill, 
including a previously determined amount of 
the available bill, responsive to the transmitted 
request for the available bill, from the second 
is location; 

wherein the relevant information includes a 
requested modification to the previously deter- 
mined amount. 

20 1 4. A method according to claim 1 0, further comprising 
the steps of: 

storing, in a database, bill availability informa- 
tion identifying a plurality of available bills of a 
25 plurality of different billers and those of the 

identified plurality of available bills which 
require information relevant to the amount of 
those available bills. 

transmitting, in real time, the stored bill availa- 
30 bility information, from the third network loca- 

tion; and 

selecting, in real time, the available bill from the 
plurality of available bills identified in the trans- 
mitted bill availability information, at the first 
35 location; 

wherein the available bill is one of those of the 
plurality of available bills requiring information 
relevant to the bill amount. 

40 15. A method according to claim 1 4, further comprising 
the step of: 

storing, in real time, the received amount in the 
database. 

45 

16. A electronic bill, payment system, comprising: 

a database configured to store bill availability 
information identifying available bills of a plural- 
so ity of different billers for a plurality of different 

users; 

a processor configured(i)to receive a real time 
network communication of an amount of one of 
the available bills identified in the stored bill 
55 availability information for a first of a plurality of 

different users from a first of the plurality of dif- 
ferent billers and a real time network communi- 
cation of an instruction to pay the available bill 
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from the first user, (ii) to transmit, in a real time 
network communication, a directive to pay the 
amount of the available bill based upon the 
received pay instruction, and (iii) to store the 
amount in the database in association with the 5 
bill availability information identifying the avail- 
able bill. 



received pay instruction. 

21. An article of manufacture according to claim 20, 
wherein the computer programming is further con- 
figured to cause the processor to operate so as to: 

to store the received amount in a database. 



17. A system according to claim 16, wherein: 

the processor is further configured to (i) receive 
a real time network communication requesting 
bills of the first user, (ii) to transmit a real time 
network communication of the stored bill avail- 
ability information identifying available bills, 
including the available bill, for the first user, and 
(iii) to receive a real time network communica- 
tion indicative of the available bill having been 
requested from the first biller 



19, A system according to claim 16, wherein: 

the database is further configured to store a 
previously received amount of the available bill; 
and 

the received amount of the available bill is sub- 
stituted for the previously received amount in 
the database. 



22. An article of manufacture according to claim 21, 
10 wherein the amount is stored in the database so as 

to replace a previously determined amount of the 
available bill previously stored in the database. 

23. An article of manufacture according to claim 20, 
15 wherein the computer programming is further con- 
figured to cause the processor to operate in real 
time so as to: 

receive a communication requesting bills of the 
first user; 

transmit bill availability information identifying 
available bills, including the available bill, for 
the first user responsive to the received com- 
munication requesting bills; 
and 

receive a communication indicating receipt of a 
request for the available bill from the first biller. 

24. An article of manufacture according to claim 23, 
wherein the transmitted bill availability information 
includes an indication that the available bill requires 
information relevant to the amount of the available 
bill. 

35 25. An article of manufacture according to claim 20, 
wherein the received amount of the available bill 
represents an adjustment to a previously received 
amount of the available bill. 



18. A system according to claim 16, wherein: 

the database is further configured to store the 
bill availability information so as to further iden- 
tify those of the identified available bills which 25 
require information relevant to the amount of 
those bills; and 

the available bill is one of those of the plurality 
of available bills further identified as requiring 
relevant information. 30 



40 

20. An article of manufacture for paying bills electroni- 
cally, comprising: 



a computer readable storage medium; and 
computer programming stored on the medium 45 
and configured to be readable from the 
medium by a computer processor and thereby 
cause the processor to operate in real time so 
as to: 

50 

receive a communication of an amount of 
an available bill of a first of a plurality of dif- 
ferent billers for a first of a plurality of differ- 
ent users determined by the first biller; 
receive a communication of an instruction 55 
of the first user to pay the available bill; and 
generate a directive to pay the received 
amount of the available bill based upon the 
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